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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief history 



The present document is one of a series of ECMA standards defining mapping functions in exchanges of Private 
Integrated Services Networks required for the utilization of intervening network scenarios. The series uses the ISDN 
concepts as developed by ITU-T (formerly CCITT) and is also within the framework of standards for open systems 
interconnection as defined by ISO/IEC. It has been produced under ETSI work item DTS/ECMA-00234. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The present document has been adopted by the ECMA General Assembly of June 2002. 
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Scope 



The present document specifies functions for using a packet network that uses the Internet Protocol (IP) as its network 
layer protocol and UDP and TCP as its transport layer protocols, to interconnect two Private Integrated services 
Network exchanges (PINXs) forming part of a Private Integrated Services Network (PISN). Interconnection is achieved 
by carrying the inter-PINX signalling protocol directly over the Transmission Control Protocol (TCP) and inter-PINX 
user information (e.g. voice) over the Real-time Transport Protocol (RTP), RTP being carried over the User Datagram 
Protocol (UDP). The inter-PINX signalling protocol is assumed to be QSIG, as specified in EN 300 172, ETS 300 239 
and other standards. 

The present document provides for two types of interconnection: 

on-demand, where a separate TCP connection for QSIG is established at the start of each call and cleared down 
at the end of that call; and 

semi-permanent, where a single TCP connection with an indefinite lifetime carries QSIG on behalf of many 
single calls. 

The present document is applicable to PINXs that can be interconnected to form a PISN using QSIG as the inter-PINX 
signalling protocol. 



Conformance 



In order to conform to the present document, a PINX shall satisfy the requirements identified in the Implementation 
Conformance Statement (ICS) proforma in annex A. 



3 References 

The following standards contain provisions which, through reference in this text, constitute provision of this Standard. 
All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the 
possibility of applying the most recent editions of the standards indicated below. 

ETSI ETS 300 475-1: "Private Telecommunication Network (PTN); Reference configuration; Part 1: Reference 
configuration for PTN exchanges (PTNXs) [ISO/IEC 1 1579-1 (1994), modified]". 

ETSI EN 300 171: "Private Integrated Services Network (PISN); Specification, functional models and information 
flows; Control aspects of circuit-mode basic services [ISO/IEC 11574 (1994) modified]". 

ETSI EN 300 172: "Private Integrated Services Network (PISN); Inter-exchange signalling protocol; Circuit-mode 
basic services [ISO/IEC 11572 (1996) modified]". 

ETSI ETS 300 239: "Private Integrated Services Network (PISN); Inter-exchange signalling protocol; Generic 
functional protocol for the support of supplementary services [ISO/IEC 1 1582 (1995), modified]". 

ITU-T Recommendation 1.112 (1993): "Vocabulary of terms forlSDNs". 

ITU-T Recommendation 1.210 (1993): "Principles of telecommunication services supported by an ISDN and the means 
to describe them". 

IETF RFC 760: "Internet Protocol". 

IETF RFC 761: "Transmission Control Protocol". 

IETF RFC 768: "User Datagram Protocol". 

IETF RFC 1889: "RTP: a transport protocol for real-time applications". 

IETF RFC 2126: "ISO Transport Service on top of the TCP (ITOT)". 
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4 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

4.1 External definitions 

The present document uses the following terms defined in other documents: 
-IVN (ETS 300 475-1) 

-PINX (ETS 300 475-1) 

-PISN (ETS 300 475-1) 

- Service (ITU-T Recommendation 1. 1 12) 

- Signalling (ITU-T Recommendation 1. 1 12) 

4.2 Other definitions 

4.2.1 Calling PINX 

In the context of a call or call-independent signalling connection across an IPL, the PINX that transmits the QSIG 
SETUP message. 

4.2.2 Called PINX 

In the context of a call or call-independent signalling connection across an IPL, the PINX that receives the QSIG 
SETUP message. 

4.2.3 Channel 

A means of bi-directional transmission of user or signalling information between two points. 

4.2.3.1 Do-Channel 

A channel used to convey call control information between the Q reference points of two peer PINXs. 

4.2.3.2 U Q -Channel 

A channel used to convey user information between the Q reference points of two peer PINXs. 

4.2.4 Resource Control Information 

Information exchanged between peer PINXs for the purpose of establishing UDP streams 

4.2.5 Inter-PINX Connection (IPC) 

A connection provided by an IVN between two C reference points used to transport inter-PINX information from the 
PISN control plane and/or the PISN user plane. 

4.2.6 QPKT 

A packet format defined within the present document for conveying QSIG message and RCI (Resource Control 
Information). 
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List of acronyms 



ip 

IPC 

IPL 

IVN 

PINX 

PISN 

QSIG 

RCI 

RTCP 

RTP 

TCP 

UDP 



Internet Protocol 

Inter-PINX connection 

Inter-PINX Link 

Intervening Network 

Private Integrated services Network eXchange 

Private Integrated Services Network 

SIGnalling information flows at the Q reference point 

Resource Control Information 

Realtime Transport Control Protocol 

Realtime Transport Protocol 

Transmission Control Protocol 

User Datagram Protocol 



Introduction 



6.1 Reference configuration 

ETS 300 475-1 defines a reference configuration for a PINX. Logically the switching and call control functions of a 
PINX communicate over an instance of the Q reference point with a peer PINX. This communication is known as an 
Inter-PINX Link (IPL) and comprises a signalling channel, known as a Dg-channel, and one or more user information 
channels, each known as a UQ-channel; see figure 1. One or more IPLs can be established between the same pair of 
PINXs. 
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Figure 1 : IPL concept 

There are many ways of implementing an IPL. In general, the IPL uses services of another network, known as an 
Intervening Network (IVN). A PINX interfaces to the IVN at the C reference point. The IVN provides connections, 
known as Inter-PINX Connections (IPCs) between the C reference points of the peer PINXs. Mapping functions within 
each PINX map the DQ-channel and the Ug-channels at the Q reference point onto one or more IPCs at the C reference 
point. 



6.2 Specific scenarios 



The present document specifies mapping functions for use when the IVN is an IP-based network that is used to provide 
the following types of IPC: 

a TCP connection for carrying signalling information and Resource Control Information; and 

a pair of UDP streams, one stream in each direction, for carrying user information over RTP. 
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A single IPL requires a single TCP connection, for support of the DQ-channel, and one pair of UDP streams per 
UQ-channel. In addition to carrying the QSIG protocol, the TCP connection is also required to carry resource control 
information for establishing the UDP streams. 

The present document supports two types of interconnection between peer PINXs: 

On-demand, where a single TCP connection for QSIG and a pair of UDP streams for user information are 
established at the start of each call and cleared down at the end of that call; 

Semi -permanent, where a single TCP connection with an indefinite lifetime carries QSIG on behalf of many 
calls. 

In the semi-permanent case, the TCP connection can support zero, one or more than one call at the same time. A pair of 
UDP streams for user information is established at the start of each call and cleared down at the end of that call. 
Figure 2 illustrates these concepts. 
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Figure 2: IPC concept (Semi-permanent) 



7 Capabilities at the Q reference point 

For each instance of the Q reference point: 

one signalling channel (Dq) for carrying the inter-PINX Layer 3 signalling protocol, and 
zero, one or more user channels (Uq) 

shall be provided. 

NOTE: In the special case of an on-demand interconnection used only for a call independent signalling 
connection, no UQ-channels are provided. 

For a UQ-channel the following bearer capability shall be provided: 

transfer mode: circuit mode; 

information transfer rate: 64 kbit/s; 

information transfer capability: speech or 3,1 kHz audio; 

user information layer 1 protocol: G.71 1 A or |i law. 
Other bearer capabilities are outside the scope of the present document. 
For a Dg-channel the following bearer capability shall be provided: 

transfer mode: packet mode; 
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information transfer rate: implementation-dependent; 

information transfer capability: unrestricted digital information. 

The functions to map Dq- and UQ-channels to an inter-PINX connection (IPC) at the C reference point are described in 
clause 9. 



8 



Capabilities at the C reference point 



The PINX mapping functions shall meet the following requirements. 



8.1 



TCP connection 



A PINX shall support a packet network interface suitable for communication according to IETF RFC 76 1 . The protocol 
stack used in the present document is described as figure 3. 



QSIG 



RCI 



QPKT 



TPKT 



TCP 



Figure 3: Protocol stack for Mapping/IP-QSIG 

The RCI provides information required to establish the media path(s). 



A TPKT is a packet format as defined in IETF RFC 2126. It is used to delimit individual messages (PDUs) within the 
TCP stream, which itself provides a continuous stream of octets without explicit boundaries. A TPKT consists of a one 
octet version number field, followed by a one octet reserved field, followed by a two octet length field, followed by the 
actual data. The version number field shall contain the value "3", the reserved field shall contain the value "0". The 
length field shall contain the length of the entire packet including the version number, the reserved and the length fields 
as a 16-bit big-endian word. 

A QPKT is a packet format as defined in figure 4. A QPKT consists of a two octet length field, followed by a single 
QSIG message, followed by RCI. The first octet of the QSIG message shall be the octet immediately following the 
QPKT length field, the last octet shall be the octet immediately preceding the RCI. The length field indicates the length 
of the QSIG message and therefore indicates the start of the RCI. 



len. 


QSIG message 


RCI 



NOTE: In most circumstances, the RCI field is omitted. 

Figure 4: QPKT structure of Mapping/IP-QSIG 

The Dg-channel shall be mapped to the well-known TCP port (4029) or to a dynamically assigned port. RCI shall be in 
accordance with annex B. 



8.2 



UDP streams 



The Ug-channel shall be mapped to a received UDP stream and a transmitted UDP stream, each carrying RTP packets. 
The received UDP stream shall be received at a local IP address and port as indicated in transmitted RCI and the 
transmitted UDP stream shall be transmitted to a remote IP address and port as indicated in received RCI. 

NOTE: If required, PINXs can use RTCP as defined in IETF RFC 1 889 to monitor the quality of RTP carried 
over UDP streams. 
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9 Mapping functions 

9.1 Mapping the D Q -channel 

For transmission, a complete QSIG message and RCI shall be embedded in a QPKT packet within a TPKT packet as 
defined in clause 8.1. The segmentation and reassembly procedures of EN 300 1 72 shall not be used. 

The RCI implicitly refers to the call to which the QSIG message relates. It shall be included in the first forward and first 
backward message of each call, and shall not be included in subsequent messages. In addition, RCI shall not be 
included with call-independent messages. 



9.2 Mapping a Ua-channel 



Each UQ-channel shall be mapped to a pair of unidirectional UDP streams with suitable transport capabilities defined 
by the RCI. The mapping function is responsible for proper packetization, de-packetization, transcoding etc. of media 
data. 



1 IPC control functions 

To establish the IPC for the DQ-channel, the PINX initiating the TCP connection needs to know the IP address of the 
other PINX. The means for determining the IP address is outside the scope of the present document. 

For the on-demand scenario, the calling PINX shall establish a TCP connection for the DQ-channel following the 
procedure specified in IETF RFC 761 whenever a call or call-independent signalling connection is to be established and 
shall clear down the TCP connection when the call or call-independent signalling connection has been cleared. 

For the semi-permanent scenario, when a call or call independent signalling connection is to be established, if a 
DQ-channel (TCP connection) exists between the peer-PINXs, the calling PINX shall use that DQ-channel. If no 

DQ-channel exists between the peer PINXs, the calling PINX shall establish a TCP connection for the DQ-channel 
following the procedure specified in IETF RFC 761. It is an implementation matter when to clear the TCP connection, 
except that it shall not to be cleared while still being used for a call or call independent signalling connection. 

For either scenario, UQ-channel establishment and clear down shall be in accordance with clauses 10.1 and 10.2 
respectively. 

1 0.1 Procedure for Ua-channel establishment 

UQ-channel establishment shall occur whenever a call is established. 

In order to establish the UQ-channel, the calling PINX and the called PINX shall each transmit RCI in accordance with 
annex B. The calling PINX shall transmit RCI in the same QPKT packet as the QSIG SETUP message. 

The called PINX shall check that the received RCI information is acceptable and if so transmit RCI in the same QPKT 
packet as the QSIG SETUP ACKNOWLEDGE message or the QSIG CALL PROCEEDING message, whichever is 
transmitted first. 

NOTE 1: EN 300 172 requires the Channel identification information element to be present in the QSIG SETUP 
message and in the QSIG SETUP ACKNOWLEDGE message or CALL PROCEEDING message, 
whichever is transmitted first. The contents of the Channel identification information element can be 
ignored on receipt. 

NOTE 2: If the first response to the SETUP message is neither SETUP ACKNOWLEDGE nor CALL 
PROCEEDING (e.g. RELEASE COMPLETE), no RCI is returned. 
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After transmitting RCI, the calling PINX shall be prepared to receive RTP packets on the IP address and port as 
specified in the transmitted RCI. 

The called PINX shall include in the transmitted RCI the same codec type and payload period as specified in the 
received RCI. After transmitting the RCI, the called PINX shall begin transmitting RTP packets to the IP address and 
port as specified in the received RCI in accordance with the codec type and payload period as specified in the received 
RCI as soon as media becomes available. The called PINX shall also be prepared to receive RTP packets on the IP 
address and port as specified in the transmitted RCI. 

After having received RCI in the first response message and after having received the CONNECT message, the calling 
PINX shall begin transmitting RTP packets to the IP address and port in the received RCI in accordance with the codec 
type and payload period in the received RCI. 

During the establishment of the UQ-channel, if either the calling PINX or the called PINX receives unacceptable 
content in the RCI, that PINX shall behave as specified in EN 300 172 for the case where the content of the Channel 
identification information element is unacceptable. 

1 0.2 Procedure for (Jo-channel clearing 

Before transmitting a QSIG call clearing message (DISCONNECT, RELEASE or RELEASE COMPLETE), a PINX 
shall stop transmitting RTP packets and shall ignore the contents of any further received RTP packets. 

After transmitting or receiving a QSIG RELEASE COMPLETE message, the PINX should release the resources 
associated with the UQ-channel. 
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Annex A (normative): 

Implementation Conformance Statement (ICS) Proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the ICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed ICS. 



A.1 Introduction 



The supplier of a implementation which is claimed to conform to the present document shall complete the following 
Implementation Conformance Statement (ICS) proforma. 

A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities 
and options of the have been implemented. The ICS can have a number of uses, including use: 

by the implementor, as a check-list to reduce the risk of failure to conform to the standard through oversight; 

by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
standard's ICS proforma; 

by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork can 
often be predicted from incompatible ICSs. 



A.2 Instructions for completing the ICS proforma 
A.2.1 General structure of the ICS proforma 

The ICS proforma is a fixed-format questionnaire divided into clauses each containing a group of individual items. 
Each item is identified by an item number, the name of the item (question to be answered), and the reference(s) to the 
clause(s) that specifies (specify) the item in the main body of the present document. 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

m mandatory (the capability is required for conformance to the standard); 

o optional (the capability is not required for conformance to the , but if the capability is implemented 

it is required to conform to the specifications); 

o.<n> optional, but support of at least one of the group of options labelled by the same numeral <n> is 

required; 

x prohibited; 

<c.cond> conditional requirement, depending on support for the item or items listed in condition <cond>; 

<item>:m simple conditional requirement, the capability being mandatory if item number <item> is 

supported, otherwise not applicable; 

<item>:o simple conditional requirement, the capability being optional if item number <item> is supported, 

otherwise not applicable. 

Answers to the questionnaire items are to be provided either in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes or No), or in the "Not Applicable" column (N/A). 
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A.2.2 Additional information 

Items of additional information allow a supplier to provide further information intended to assist the interpretation of 
the ICS. It is not intended or expected that a large quantity will be supplied, and a ICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of additional information may be entered next to any answer in the questionnaire, and may be 
included in items of exception information. 



A.2.3 Exception information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the Support column an x.<i> 
reference to an item of exception information, and to provide the appropriate rationale in the exception item itself. 

An implementation for which an exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the Standard has been reported, a correction for 
which is expected to change the requirement not met by the implementation. 



A.3 ICS proforma for ECMA-336 
A.3.1 Implementation identification 



Supplier 




Contact point for queries about the ICS 




Implementation name(s) and version(s) 




Other information necessary for full 
identification, e.g. name(s) and version(s) 
for machines and/or operating systems; 
system name(s) 





Only the first three items are required for all implementations; other information may be completed as appropriate in 
meeting the requirement for full identification. 

The terms name and version should be interpreted appropriately to correspond with a suppliers terminology (e.g. type, 
series, model). 



A.3. 2 Implementation summary 



Implementation version 


1.0 


Addenda implemented (if applicable) 




Amendments implemented 




Have any exception items been required 
(see clause A.2.3)? 


No [ ] Yes [ ] 

(The answer Yes means that the implementation does not conform to this 

standard) 




Date of Statement 
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A. 4 General requirements 



Item 


Question/feature 


References 


Status 


N/A 


Support 


A1 


Support of on-demand IPC 




m 




Yes[] 


A2 


Support of semi-permanent IPC 









Yes [ ] No [ ] 



A.5 Ucrchannel bearer capabilities at the Q reference 
point 



Item 


Question/feature 


References 


Status 


N/A 


Support 


B1 


Support transfer mode as "circuit mode" 


7 


m 




Yes[] 


B2 


Support 64 kbit/s information transfer rate 


7 


m 




Yes[] 


B3 


Support "speech" for information transfer 
capability 


7 


0.1 




Yes [ ] No [ ] 


B4 


Support "3,1 kHz audio" for information transfer 
capability 


7 


0.1 




Yes [ ] No [ ] 


B5 


Support "G.711A-law" for user information layer 1 
protocol 


7 


0.2 




Yes [ ] No [ ] 


B6 


Support "G.71 1 u-law" for user information layer 1 
protocol 


7 


0.2 




Yes [ ] No [ ] 


B7 


Support other user information layer 1 protocol 
(specify: ) 


7 







Yes [ ] No [ ] 



A.6 D Q -channel capability at the Q reference point 



Item 


Question/feature 


References 


Status 


N/A 


Support 


C1 


Support of "packet mode" as transfer mode 


7 


m 




Yes[] 


C2 


Support of "unrestricted digital information" for 
information transfer capability 


7 


m 




Yes[] 



A.7 Capabilities at the C reference point 



Item 


Question/feature 


References 


Status 


N/A 


Support 


D1 


Support of QPKT packet structure 


8.1 


m 




Yes[] 


D2 


Support of well-know TCP port (4029) for 
D Q -channel 


8.1 


m 




Yes[] 


D3 


Support of dynamically assigned TCP port for 
D Q -channel 


8.1 







Yes [ ] No [ ] 


D4 


Support of dynamically assigned UDP port as 
signalled by RCI 


8.2 


m 




Yes[] 



A.8 Mapping functions 



Item 


Question/feature 


References 


Status 


N/A 


Support 


E1 


Support mapping of the D Q -channel 


9.1 


m 




Yes[] 


E2 


Support mapping of the U Q -channel 


9.2 


m 




Yes[] 
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A.9 


IPC control functions 






Item 


Question/feature 


References 


Status 


N/A 


Support 


F1 


Support establishing / clearing of the D Q -channel 
for the on-demand scenario 


10 


m 




Yes[] 


F2 


Support establishing / clearing of the D Q -channel 
for the semi-permanent scenario 


10 


A2:m 


[] 


Yes[] 


F3 


Support establishing of the U Q -channel 


10.1 


m 




Yes[] 


F4 


Support clearing of the U Q -channel 


10.2 


m 




Yes[] 





A. 10 Support of resource control information 
A.1 0.1 Support of bearer capabilities information 



Item 


Question/feature 


References 


Status 


N/A 


Support 


G1 


Support codec type "g71 1 Alaw64k" 


B.2.3.1 


0.1 




Yes [ ] No [ ] 


G2 


Support codec type "g71 1 Ulaw64k" 


B.2.3.1 


0.1 




Yes [ ] No [ ] 


G3 


Support codec type "g723.1 " 


B.2.3.1 


0.1 




Yes [ ] No [ ] 


G4 


Support codec type "g729" 


B.2.3.1 


0.1 




Yes [ ] No [ ] 


G5 


Support codec type "g729AnnexA" 


B.2.3.1 


0.1 




Yes [ ] No [ ] 


G6 


Support codec type "g729wAnnexB" 


B.2.3.1 


0.1 




Yes [ ] No [ ] 


G7 


Support codec type "g729AnnexAwAnnexB" 


B.2.3.1 


0.1 




Yes [ ] No [ ] 


G8 


Support payload period (specify: msec) 


B.2.3.1 


m 




Yes[] 



A.1 0.2 Support of IP address type 



Item 


Question/feature 


References 


Status 


N/A 


Support 


H1 


Support of IP address type "IPv4" 


B.2.3.2 


m 




Yes[] 


H2 


Support of IP address type "IPv6" 


B.2.3.2 







Yes [ ] No [ ] 
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Annex B (normative): 

Message syntax for Resource Control Information 



B.1 Introduction 



This annex defines the syntax for RCI, which is exchanged between peer PINXs for the purpose of establishing a pair of 
IPCs for providing a UQ-channel. A PINX shall be capable of transmitting and receiving RCI in accordance with this 
syntax. 



B.2 Message syntax 



Octet 8 
group 
1 

2 
3 



Resource control header 



Protocol indicator 



Resource control information 



Reference 

B.2.1 
B.2.2 
B.2.3 



B.2.1 Resource control header 



Octet 
1.1 
1.2 



8 


7 


6 


5 


4 


3 


2 


1 





1 


1 


1 


1 


1 


1 





X 


X 


X 


X 


X 


X 


X 


X 



Resource control discriminator 
Length of entire RCI 



B.2.2 Protocol indicator 



Octet 8 

2.1 

2.2 



8 


7 


6 


5 


4 


3 


2 


1 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 



Protocol identifier 
Version identifier 



"Protocol identifier" is coded as follows: 



Bit 



1 



00000000 
Others 



ECMA-336 
Reserved 



"Version identifier" is coded as follows: 



Bit 







Version information 



B.2.3 Resource control information 



Octet 
group 

3.1 
3.2 



X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 



Description 


Reference 


Bearer capabilities information 


B.2.3. 1 


UDP stream information 


B.2.3. 2 
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B.2.3.1 Bearer capabilities information 



Octet 

3.1.1 
3.1.2 
3.1.3 



8 


7 


6 


5 


4 


3 


2 


1 

















1 








X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 



Bearer capabilities information discriminator 
Type of codec (any value from the list below) 
Payload period (unit: milliseconds.) 



Type of codec is coded as follows: 



Bit 
























g711Alaw64k, 

















1 


1 


g711Ulaw64k, 














1 








g723.1 with silence compression, 














1 





1 


g723.1 without silence compression 











1 





1 





g729, 











1 





1 


1 


g729AnnexA, 











1 


1 


1 





g729wAnnexB, 











1 


1 


1 


1 


g729 AnnexAwAnnexB , 


Others 














Reserved 



B. 2.3.2 UDP stream information 

UDP stream information is coded as follows: 

17 6 5 4 3 2 1 



Octet 

3.2.1 
3.2.2 
3.2.3 

to 
3.2.3+ 

n-1 
3.2.3+ 

n 

3.2.3+ 

n+1 







1 











UDP stream information discriminator 
Type of IP address 
IP address (n octets) (note 1) 



UDP port number for RTP (note 2, note 3) 



NOTE 1: Octet 3.2.3 contains the most significant octet of the IP address. 
NOTE 2: The RTCP port number should be one greater than the RTP port number. 
NOTE 3: Octet 3.2.3+n contains the most significant octet of the UDP port number. 
"Type of IP address" is coded as follows: 



Bit 



4 



1 



00000000 
10 
Others 



IPv4 address 

IPv6 address, optional 

Reserved 
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The length of field of "IP address" (n octets) depends on the type of IP address. For an IPv4 address this field 
occupies 4 octets. For an IPv6 address this field occupies 16 octets. For example, if an IPv4 address is used, 
octets 3.2.1 to 3.2.8 are coded as follows: 



Octet 

3.2.1 
3.2.2 
3.2.3 
3.2.4 
3.2.5 
3.2.6 
3.2.7 
3.2.8 



8 


7 


6 


5 


4 


3 


2 


1 











1 






































1 





1 





1 


1 








1 
1 











1 





















































1 


1 





1 


1 





1 






1 


1 


















UDP stream information (RTP) 
Type of IP address 
IP address (172.16.1.1) 



UDP port number for RTP (56 000) 
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